Intro

2024년 갑진년이 밝았습니다. 청룡의 해 첫 출근을 마치고 글을 쓰려고 오랜만에 앉으니 감회가 새롭습니다.

오래 동안 블로그를 어떻게 운영해야하나 고민 했습니다. 내 블로그가 기술 블로그로써 가치가 있으려면 어떻게 해야 할까? 라는 고민이 들었고, 오랜 고민끝에 블로그의 운영 방향을 정하고 초심으로 돌아가기로 했습니다.

가능하면 개인 공부에 대한 글 보다는 기술에 대한 고민이 조금이라도 들어간 글을 남기기로 했고, 그동안 작성하였던 공부 포스팅은 모두 TIL 노션 글로 옮기고자 합니다.

Notion TIL 문서

노션에는 하루에 하나씩 작은 TIL 글이라도 작성하려고 합니다. 얼마나 갈 지는 모르겠지만요...ㅎㅎ 그저 잔디나 채우고자 하는 목적으로 이 블로그를 운영하고 싶지는 않다는 생각이 들어서 내린 판단입니다.

회고를 하는 데 있어 각자의 이유가 있겠지만, 개발자에게 회고란 인플루언서들의 인스타그램 피드와 같은 것 아닐까요? 화려한 모습으로 어필하자니 인플루언서가 될 능력이라면 반드시 개발자를 하지 않아도 되었겠지요...? 농담입니다ㅋㅋ...

사실 누가 읽으라고 쓰는 거라기 보단 스스로 돌아보려고 쓰려는 목적이 강합니다. 이렇게라도 스스로 돌아볼 기회가 없다면, 매년 발전하는 모습을 보이기 힘들겠지요.

2023년의 시작

2023년은 실질적으로 대학을 졸업 한 이후 다양한 프로젝트를 경험 하며 시작했습니다. 사실 명목상의 졸업은 2022년 2월입니다. 2023년의 상반기는 현재 회사에서 일을 하기 전 까지 실무 경험을 쌓던 해였습니다.

사실 시작이 썩 기분 좋은 해는 아니었습니다. 새로운 도전을 한다고 스스로 말은 하고 있지만, 현실은 튜토리얼 지옥에서 벗어나지 못 하고 있었으니까요.

2022년 한 해동안의 인턴십 경험은 큰 도움이 되었으나, 너무나 성급했다고 생각합니다. 여러 압박감 속에 빠르게 취업해야겠다고 내린 판단은 독으로 돌아왔었습니다. 빠른 취업을 원했던 것 만큼 제가 원했던 포지션에서 요구하는 퍼포먼스의 기대치에 턱 없이 부족한 스스로가 원망스러웠습니다.

원인을 되짚어보면 그 당시에 취업 준비에 대한 경험도 부족했고 개발자로써의 경험도 부족했습니다. 당연히 실무적인 인사이트가 부족했기 때문에 스스로는 열심히 했다 생각했겠지만, 냉정하게 바라보면 그저 남들 하는 것을 따라하는 것 그 이상 그 이하도 아니었다고 스스로는 평가하고 있습니다.

학부시절에는 웹 개발자 진로를 깊게 생각했던 건 아니었습니다. 백엔드 개발에는 관심이 있었으나 프로젝트 하나를 제대로 실패해본 이후로 한동안 ML과 데이터사이언스 분야에 관심을 돌렸었죠.

(웹이든 모바일이든 당시에 서비스 개발 프로젝트는 정말 처다도 보고싶지 않던 시기었습니다...참 어렸었네요.)

졸업작품 개발 당시 임베디드 소프트웨어와 딥러닝, 영상처리에 관심을 가지게 되었고 그 분야로 자연스럽게 진출할 줄 알았지만, 학부 생 수준에서 요구하는 퍼포먼스를 내기 힘들다는 결론을 내렸습니다. 오랫동안 대학원을 고민하다가 빨리 돈을 벌고 싶다는 생각에 취업 준비 전선으로 뛰어 들었었습니다. 만약 그때로 돌아갔다면 어떤 판단을 내렸을까 궁금하네요...

학부시절 당시에 웹에도 관심이 있던 것은 맞지만, 웹 프로젝트 경험이 턱 없이 부족한 당시의 저는 참 막막했던 것 같습니다. 그래서 정규직 전환이 되지 않더라도 인턴십에 일단 부딪쳐 보자 라는 생각으로 도전하였습니다. 결과적으로는 너무나 좋은 경험이었습니다. 어쨌든 코딩테스트 문제들이 어떻게 나오는 지 경험 해 보았고, 입문자 수준이었던 백엔드 애플리케이션 개발 경험이 최소한 발은 담궈 보았다 수준으로 쌓였으니까요.

그래서 2023년의 시작은 개인 프로젝트 부터 시작했습니다. 제 퍼포먼스는 너무나 부족하며, 경험이 백엔드 개발에만 치우쳐 져 있다고 판단했습니다. 더 실력을 쌓아서 새로운 도전을 해 보고자 판단하였고 인턴십 종료와 함께 GCP 계정을 생성하였습니다.

트위터 클론 프로젝트

노마드 코더 Twitter 클론코딩 강의

2022년 한 해동안의 실무 경험으로 절대 한 포지션에 대한 경험 만 쌓아서는 안됀다. 라는 판단을 했고, 풀스택으로 작은 서비스라도 직접 개발해서 배포까지 진행 하자는 계획을 세웠습니다. 과거에 React.js 를 공부하기 위해 위 강의를 들었는데, 이번 프로젝트에선 Firebase로 구현되어있던 모든 백엔드를 걷어내고 Spring Boot 로 대체하는 것을 목표로 삼았습니다. 또한 GCP의 모든 서비스를 쓰지 않고 일반적인 온프레미스 상황을 가정하기 위해 VM 하나에서 모든 셋업을 진행 해 보는 것을 다음 목표로 삼았습니다.

이 프로젝트를 하기 전 AS-IS는 다음과 같았습니다.

몇 번의 실무 프로젝트 경험으로 인해 Spring Boot 개발 경험이 있었다.
프론트엔드는 React를 사용해 본 경험이 있었다.

하지만 냉정하게 잘 한다고 볼 수는 없었다고 생각합니다. 혼자서 인증을 구현하는 과정도 어려웠지만, 프론트엔드와 연동하는 과정에서 많은 시행착오를 겪어야 했습니다. 대표적으로는 아래와 같습니다.

인증 구현 및 연동 과정에서 터지는 무수한 에러를 어떻게 핸들링 할 것인 지?
Controller 레이어 부터 터지는 에러를 어떻게 효율적으로 핸들링 할 것인 지?
프론트엔드를 실제로 어떻게 배포 할 것인 지?
백엔드까지 배포는 하겠는데 어떻게 SSL을 도입 할 것인지?
그래서 어떻게 배포 할 것인 지?

사실 기능은 간단했습니다. 게시글 CRUD 와 프로필 변경, 이미지 첨부 정도였죠. 지금의 인사이트로는 그냥 AWS 든 GCP든 대충 써서 개발하면 되지 않는가 라는 생각이 들지만, 그 당시엔 제 스스로 결정한 미션에 의해 VM 내에 저장해서 NGINX로 불러다 쓰고 있었죠. 가능하면 IaaS 서비스를 다 써먹기보단 온프레미스 환경을 가정해서 개발해보자는 판단이었습니다. 물론 좋은 경험이었습니다. 덕분에 모든 배포 과정을 맨땅에서 부터 지지고 볶을 수 있었으니까요.

기능을 구현하는 데는 한달이 채 걸리지 않았습니다만, 문제는 배포였습니다. 당시의 전 배포를 경험 해본 적은 있으나, 백지부터 웹 애플리케이션 아키텍쳐를 구성해본 경험은 많지 않았습니다. Apache 서버가 배치되어있는 환경에서 Virtual Host 설정만 변경해서 배포를 했었죠. 문제는 프론트엔드와 백엔드 애플리케이션을 각각 어떻게 배포하느냐였습니다.

당시에는 각자 배포하는 방법을 택했습니다. 당시의 판단으로는 VM에 배치 된 NGINX 에 직접 웹뷰를 배포하자는 판단을 미처 하지 못했었습니다. Netlify 라는 빠르고 쉬운 길을 선택했죠. 지금 다시 프로젝트를 한다면 그냥 Spring과 함께 배포시키거나, 서버에 배포시켜놓고 NGINX에서 경로 설정을 해주는 방식으로 처리했지 않았을까요?

프론트엔드는 배포 경험이 부족했지만, 백엔드는 그래도 그동안 쌓은 경험을 토대로 Docker Compose 를 셋업하여 배포했습니다. SSL 인증서는 CertBot 으로 처리했고 Portainer 를 통해 VM 내에 컨테이너들을 웹으로 관리했습니다. 당시엔 도커 명령어가 익숙하지 않았어서 Portainer를 사용하였었죠.

최종 배포를 마친 모습은 아래와 같습니다.

로그인 화면		메인 화면

작은 프로젝트를 혼자 개발 배포해봄으로써 당시 까지의 실무 경험을 다시 돌아볼 수 있었습니다. 프론트엔드와 백엔드를 함께 연동하면서 해결해야 할 CORS 문제, 인증, 상태관리 등의 문제들을 해결하며 프론트엔드 개발에 대한 경험이 더욱 쌓였고, 기존의 전문분야로 삼았던 백엔드의 인사이트가 한층 더 깊어졌습니다. React 를 정말 짧게 독학했었는데, Redux를 도입하며 Ducks 패턴, 디렉토리 구조 등 프로젝트를 셋업할 때 고려해야 할 인사이트들을 쌓을 수 있었습니다.

또한 혼자서 DB를 설계 해 보며 JPA 에서 N:M 관계를 처리하는 방법이나 Projection 오브젝트를 통한 원하는 데이터만 패칭하는 법, DTO와 VO의 차이점 등 백엔드의 기본기를 쌓는 데 큰 도움이 되었습니다. 결국 백엔드는 DB를 잘 알아야 하니까요.

부트캠프 스파로스 아카데미

스파로스 아카데미 홈페이지

당장 혼자서 프로젝트를 해 봐야 '내가 얼마나 잘 하고 있는건 지?' 전혀 알 수 없었습니다. 인턴십으로라도 회사를 다닐 때는 코드를 리뷰 받을 기회라도 있었지만, 정작 혼자 한 프로젝트를 리뷰 할 사람이 나 자신 뿐이라는 사실이 절망스러웠습니다. 그래서 오랜 고민 끝에 신세계 아이앤씨에서 주최하는 스파로스 아카데미 2기 에 참여하였습니다.

부트캠프를 고르기 전의 기준은 먼저 '프로젝트 중심 교육과정' 이었습니다. 이미 1년 가량의 실무 경험이 존재했던 당시의 저에게 JAVA 문법이나 Spring Boot 프로젝트 셋업 법을 처음부터 배우는 것은 큰 의미가 없다고 생각했습니다. 그래서 100% 프로젝트 중심 이라는 스파로스 아카데미에 관심이 생겼습니다. 다음으로 '결과물이 나올 것' 이었습니다. 당연한 얘기지만 결과물이 없어서는 배울 게 없기도 하고 제 스스로가 그 당시까지 결과물을 제대로 내 본적이 몇 번이나 있는 지 반성하는 차원에서 결과물이 제대로 나오는 프로젝트를 반드시 경험하고자 하였습니다.

스파로스 아카데미의 결과물들은 교육과정에 대한 기대감을 가지기에 충분했고, 망설임 없이 지원했습니다. 제 본가인 부산에서 교육을 진행하는 것 또한 메리트가 컸습니다. 부트캠프를 위해 서울에서 계속 지내자니 여러 모로 현실적으로 어려움이 컸기 때문입니다.

선발 과정

코딩테스트 후 면접을 보았습니다. 코딩테스트의 결과가 선발에 큰 영향은 없지만, 추후 성장 과정에서 평가의 척도로 결정 될 수 있었습니다. 모든 문제를 풀지는 못 했고 난이도는 기업 코딩테스트 보다는 쉬웠으나, 마지막 그래프 탐색 문제에서 해메고 말았습니다.

면접 난이도는 어렵지 않았습니다. 이미 인턴을 경험 해 본 입장에서 다시 부트캠프를 하려는 이유에 대한 질문이 나왔었습니다. 너무나 성급한 인턴 경험으로 인해 실무 경험은 쌓였으나, 내실이 부족한 상황에서 부트캠프가 절실히 필요한 상황이라고 설명 드렸고 최종적으로 합격하였습니다.

프로젝트 과정

스파로스 아카데미의 교육 과정은 1차, 2차 프로젝트로 나뉩니다. 1차 프로젝트는 서비스 클론 코딩, 2차 프로젝트는 기업 연계 프로젝트였고 2차 프로젝트의 난이도가 상당히 있는 편이라 1차 프로젝트는 많은 스킬업 시간이 존재했습니다. 앞서 말씀드렸듯이 100% 프로젝트 중심 교육과정 이었기 때문에 기초에 대한 설명은 진행되지 않았지만, 부트캠프였기 때문에 모든 학생들이 경험이 풍부하지 않았습니다. 솔직히 말씀드리자면 100% 프로젝트로 진행되는 교육과정에서 웹 개발 경험이 전무한 학생이라면 많은 애로사항이 있을 수 있기 때문에 강사님의 스킬업 시간은 필수였습니다.

역할

당시에 경험이 있는 학생들 중심으로 팀이 빌드되었고, 마음이 맞는 학생들 끼리 스터디 모임이 생겼습니다. 저는 프로젝트 팀장과 동시에 백엔드 스터디 장을 맡게 되었습니다. Twitter 클론코딩 프로젝트에서 Spring Security 핸들러들을 커스텀 한 경험이 백엔드 스터디 장이 되는 데 큰 역할을 했습니다.

또한 1차 프로젝트도, 2차 프로젝트도 팀장을 맡았었습니다. 학부 시절 잦은 팀장, 동아리 간부 경험을 통해 조직관리를 경험 해 보았으나, 개발 팀을 직접 운영 해본 것은 학부 캡스톤 디자인 이후로 처음이었습니다. 학부 시절에 팀장을 하던 때와는 사뭇 달랐습니다. 당시에도 SW Engineering 수업 시간에 배웠던 에자일 방법론에서 필요한 부분들을 많이 써먹었으나, 학부생 신분일 때와는 사뭇 달랐습니다.

주 포지션은 풀스택 개발이었습니다. 저 또한 '풀스택을 지향하되, 전문 분야는 확실히 가지고 가자.' 라는 입장이었고, 경험을 조금이라도 더 쌓고 싶었습니다. 1차 프로젝트 땐 배포 및 인프라 구성까지 직접 진행했으나, 2차 프로젝트 땐 데브옵스 포지션을 가져 간 팀원 덕분에 배포와 관련 된 고민에서 자유로웠습니다. 덕분에 저도 어깨넘어로 Kubernetes를 배웠고, ELK 외에도 Grafana, Loki 를 통해서 로그 모니터링을 할 수 있다는 것을 배웠었습니다.

팀을 운영하며 배웠던 점

많은 것을 배웠지만 정리하면 아래와 같습니다.

프로젝트의 목적에 대한 공감대가 형성 되어야 한다. 누군가에게 이 프로젝트는 그다지 와닿지 않을 수 있다. 그런 팀원에게는 프로젝트의 의미를 부여해주기 위해 노력해야 한다.
팀장은 팀원들의 포텐셜을 제대로 이해하고 있어야 한다. '잘 할것 같아서' 라는 이유 보다는 조금 냉정하더라도 명확한 판단의 근거를 위해 많은 소통을 진행해야 한다.
팀장은 팀원들의 R&R을 명확히 명시해야 하고 팀원은 해당 R&R에 동의한다면 충분히 잘 따르어야 한다. 동의하지 않는다면 명확한 이유를 가지고 합의해야 한다.
데일리 스크럼과 데일리 회고는 팀의 소통에 매우 큰 역할을 한다. 정말 짧게라도 좋으니 팀원 간의 업무 현황은 반드시 공유되어야 한다.

항상 팀이 안정적으로 운영되지는 않았습니다. 1차 프로젝트의 경우 참 공교롭게도 중도 포기자가 너무 많이 나와서 부족한 리소스 내에서 개발을 진행해야 했고, 2차 프로젝트 또한 풀스택으로 진행해야 했습니다. 그 과정에서 소통 오류도 많았고 속상할 일도 많았습니다. 하지만 어쨌든 부트캠프 내에서의 프로젝트고, 아무리 교육과정이 100% 프로젝트 중심 과정이라고 해도 모두가 프로젝트를 경험하진 않았기에 팀장으로써 희생한다는 생각으로 프로젝트에 임했습니다.

그리고 2023년 초에 개인 프로젝트를 진행했던 게 이렇게 빛을 발하구나 라는 생각을 많이 했던 것 같습니다. 누군가는 '팀장을 맡아봐야 장점이 무엇이 있겠느냐?' 라고 얘기했었지만, 제 생각은 이럴 때 아니면 팀장을 맡기 위해선 오랜 시간이 지나야 한다는 판단이었기 때문에 적극적으로 리더 역할을 자처했습니다. 덕분에 소통 역량과 인사이트가 크게 향상되었다고 생각합니다. 과거에 학부때는 찍어누르듯이 프로젝트의 의사 결정을 진행한 적도 있었습니다만, 부트캠프에서는 매번 회의를 통해 프로젝트를 진행하는 의미, 서비스의 목적에 대한 대화를 많이 나누었습니다.

기술적으로 배웠던 점

2차 프로젝트는 마이크로 서비스 개발이라는 과제가 주어졌습니다. 스파로스 아카데미가 다른 부트캠프와는 다른 차별점을 가지는 점 중 하나였습니다. 100% 프로젝트만 진행된다는 점과 별개로 마이크로 서비스를 구현하기 위해서라도 알아야 할 다른 지식들을 쌓을 수 있었습니다.

특히 백엔드 애플리케이션들이 분리되어서 배포 된 환경에서 다른 도메인과 협업이 필요 한 경우, 모놀리식이었다면 크게 고민하지 않았을 문제들이 마이크로 서비스였기 때문에 많은 시행착오를 겪었습니다. 예를 들면 조회 시 JOIN으로 가져올 수도 있는 로직들이 DB가 분리되어 있는 경우였습니다. 이런 상황은 처음 겪어봤기 때문에 많은 고민과 시행착오를 겪었습니다.

그 과정에서 CQRS 와 API 조합패턴 등의 선택지를 알게 되었습니다. 기간이 촉박해서 CQRS를 도입하지는 못했지만, 이런 프로젝트를 경험하지 못한 채 혼자 공부했다면 절대로 쌓을 수 없는 인사이트를 얻게 되었다고 생각합니다.

Kafka 같은 이벤트 스트리밍 또한 경험하게 되었고 백엔드 애플리케이션 간 협업을 통해 대규모 트래픽을 분산 처리하는 경험, KeyCloak 을 통한 SSO 구현, Kubernetes 를 통한 서비스 배포 등 스파로스 아카데미에서의 프로젝트 경험이 아니었다면 쌓기 힘들었을 법 한 경험들을 쌓게 되었고 2023년 최대 수확 중 하나라고 생각합니다.

BIBOT 서비스 최종 아키텍쳐 구성도

BIBOT 서비스 내 경비 처리 로직 시퀀스 다이어그램

1차 프로젝트 스타벅스 쇼핑몰 클론코딩 시연

검색		주소록 관리		단건 결제

장바구니 결제		구매 목록 확인

2차 프로젝트 BIBOT 시연

스플래시 화면 및 메인		카테고리 별 경비 현황 조회		공지사항 조회

카드 결제 기록 조회		경비 요쳥 및 내역 조회		경비 처리 실패 및 재처리

프로필 사진 변경		다크모드

어쨌든 취업

부트캠프가 끝나고 한달 반 가량의 취업 준비 끝에 현재의 회사에 입사하게 되었습니다. 대략 30개 이상의 이력서를 작성하였고 수도 없이 코딩테스트를 보았습니다.

그 과정에서 부트캠프 당시 알게 된 사람들과 인연을 이어가며 코딩 테스트 스터디, 백엔드 스터디를 계속해서 리드하였고, 스파로스 아카데미 과정 이후에도 담당 분들과 소통하며 모의면접, 자소서 및 포트폴리오 첨삭을 받았습니다. 그 과정에서 스스로가 무엇을 했는 지 명확하게 작성할 수 있어야 한다. 라는 인사이트를 얻었고, 단순 구현 기록이 아니라 개선하려고 노력했던 부분을 최대한 포트폴리오에 녹여냈습니다.

한달 반의 기간동안 너무나 정신없이 흘러갔고, 정신 차려보니 합격 통보를 받게 되었습니다. 올해 가장 기분이 좋았고 스스로 뿌듯함을 느꼈던 8월이 아니었나 싶네요.

여러 선택지가 있었지만, B2C를 하고싶었고(다양한 유저들의 요구사항을 커버 해 보고 싶었습니다.) 핀테크 등 금융 업계에 관심이 커서 라는 이유로 현재의 회사를 선택했습니다. 나머지 선택지들은 아무리 지금 회사보다 규모가 크더라도 마음에 없던 회사였거나, 마음에는 있었으나 성장의 기회가 부족하다는 판단을 했습니다. 주니어때는 회사의 규모 보단 많은 업무 경험에 대한 기회가 판단 기준이 되어야 한다고 생각했습니다. 그 결과 연말까지 많은 경험을 쌓을 수 있었습니다.

입사 한 이후론 정말 정신없이 하루하루가 흘러갔던 기억이 나네요. 지금까지 쌓아왔던 인사이트를 자유롭게 펼쳐 볼 수 있었고, 그 과정에서 또 다른 인사이트를 쌓을 수 있었습니다. 직접 AA를 진행하며 경험으로써 CQRS와 같은 개념을 경험해볼 수 있었고, DDD를 진행 해 보며 도메인이라는 개념을 정립할 수 있었습니다. 부트캠프를 할 때만 해도 헥사고날 아키텍쳐나 도메인 주도 설계에 대한 이해도가 부족했는데, 앱 서버 AA를 경험 함으로써 당시 보다는 이해도가 높아졌던 것 같습니다.

또한 객체지향에 대한 이해도가 더욱 높아진 것 같습니다. 공부 해 보았던 디자인패턴을 직접 써먹어 보며 왜 많은 회사들의 질문에서 인터페이스, 추상클래스, 클래스 의 차이점을 물어보는 지 정말 많이 와닿았었습니다.

Outro

회고하는 데 여러가지 방법들이 있다고 하지만, 2023년의 회고는 그냥 일기장 처럼 작성 해 보았습니다. 2022년이 미완과 미숙 그 자체였다면, 2023년은 그래도 1년차로써의 퍼포먼스는 내고 있는건가? 하는 생각이 듭니다. 여전히 부족하고 해야 할 게 많습니다. 2024년에 목표했던 것들과 회사에서 앞으로 진행해야 할 일들을 생각하면 올해도 참 정신없이 흘러갈 것 같습니다만, 기대가 큽니다.

2023년은 분명 정신없고 시끄러웠지만, 결국 공부만 하다 한 해의 반 정도를 보냈었죠. 2024년은 현업 개발자로써 최고의 퍼포먼스를 내며 더 많은 인사이트를 얻을 수 있다는 기대감이 큽니다.

앞으로 더 즐겁게 지나갈 갑진년을 기대하며 회고를 마칩니다.

[회고] - 2023년 회고